Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

core(lantern): allow non-XHRs to depend on CPU Nodes #11767

Merged
merged 13 commits into from
Dec 11, 2020

Conversation

warrengm
Copy link
Contributor

@warrengm warrengm commented Dec 4, 2020

Summary
This fixes an issue that @jburger424 found in a test page where we deliberately inserted a long task before loading a script, but that wasn't reflected in results. (So the simulated load time was actually better than the real load time)

More generally I don't think we want to special case XHRs since it ignores fetch and jsonp requests which are similar enough.
Impact is as follows:

lantern allowing all

I found that excluding images and stylesheets does reduce LCP error--which is somewhat surprising because I would expect those edges to be more accurate for pages that dynamically insert images. I'd think we want to capture the impact of long tasks on LCP in those cases.

Related Issues/PRs
It seems to have been implemented this way from the start: #3162. Not sure why the decision was made to ignore XHRs though.

@patrickhulce
Copy link
Collaborator

Thanks so much @warrengm this looks like a great improvement from the numbers! 🎉

Conceptually they were excluded because ResourceSendRequest happened for all network initiation activity that happens to occur in a task, not just activity directly caused by the currently executing script. That was too wide of a net to cast back in 2017 based on scheduling, prevalence of XHR capturing many important cases already, our poor ability to detect graph cycles, etc, so we generally stayed conservative unless there was a definitive win in the error numbers. I definitely believe enough changes have moved in our favor over the past 3 years for the calculus to have flipped here though, and we just weren't actively revisiting any of it so thank you :)

My hunch on what you're seeing with images and stylesheets is what remains of that original concern, but definitely appears to be a big win overall 🎉

More generally I don't think we want to special case XHRs since it ignores fetch and jsonp requests which are similar enough.

For sure, the safest version of this change that sticks with the original conservativeness would be only expanding this to fetch and other scripts rather than all network requests. If that preserves a majority of the accuracy improvements, that'd probably be my ideal change, but if the aggregate wins do come from other types, then I think we're in a much better place to proceed there today too than we were in 2017.

@warrengm
Copy link
Contributor Author

warrengm commented Dec 4, 2020

Updating the condition to improve accuracy sounds good!

Carving out Image and Stylesheets had an improvement, but carving out Other and undefined was worse in my testing. However I hadn't tried just xhr, fetch, and jsonp yet. I'll run a few more tests and let you know what I find.

I also had some thoughts about it probably matters whether the request was initiated at the start of the task or the end, but that is probably too hard to model now.

@connorjclark
Copy link
Collaborator

FYI our target release for v7 is Wed/Th. Let us know if you need an assist here.

@warrengm
Copy link
Contributor Author

warrengm commented Dec 9, 2020

I'll have the PR ready by later today--I mostly need to finish updating tests.

After some testing, I think excluding images, stylesheets, and fonts is a good option to reduce the error on LCP results (with some trade-offs in a smaller improvement on speed index simulation):

lantern ignoring images

@warrengm warrengm changed the title core(lantern): Allow non-XHRs to depend on CPU Nodes core(lantern): allow non-XHRs to depend on CPU Nodes Dec 9, 2020
@patrickhulce
Copy link
Collaborator

sounds good @warrengm let me know if you need any help here!

@warrengm warrengm marked this pull request as ready for review December 9, 2020 19:00
@warrengm warrengm requested a review from a team as a code owner December 9, 2020 19:00
@warrengm warrengm requested review from adamraine and removed request for a team December 9, 2020 19:00
@warrengm
Copy link
Contributor Author

warrengm commented Dec 9, 2020

I think this is good to review. The failures seem to be the same that have been discussed for other PRs

Copy link
Collaborator

@patrickhulce patrickhulce left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

cool cool cool! the redirectedResourceType and one test diff only obstacles I see, looks great otherwise, thanks for this! 💯

lighthouse-core/lib/network-request.js Outdated Show resolved Hide resolved
"default": 1330,
"justTTI": 800,
"default": 960,
"justTTI": 960,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we might need to adjust the test graph we use so these are different

@@ -266,7 +266,7 @@ describe('Byte efficiency base audit', () => {
const result = await MockAudit.audit(artifacts, {settings, computedCache});
const resultTti = await MockJustTTIAudit.audit(artifacts, {settings, computedCache});
// expect less savings with just TTI
expect(resultTti.numericValue).toBeLessThan(result.numericValue);
expect(resultTti.numericValue).toBeLessThanOrEqual(result.numericValue);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this assertion was hard coded because it is the test :) we'll need to construct a different graph to get the same value if TTI is the same as the last node timing now

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it cool to have computeWasteWithTTIGraph just return a fixed number? IMO that would make it clear that were testing subclassing.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's fine if we don't have any other traces that are different in this regard. I'd be bummed to lose a bit of the double duty testing that computeWasteWithTTIGraph does its job correctly, but we can address that another time.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That makes sense. I cheated to get the test to pass now since I'm not sure how to construct the right graph.

Here it might be good to have each unit tests test one thing. So maybe test computeWasteWithTTIGraph directly by calling it with different options or at least have sibling classes where you're not testing overriding.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

:) you're right of course and we should finally get around to that since this base is the foundation of many different opportunities. filed #11802 👍

lighthouse-core/test/fixtures/lantern-master-accuracy.json Outdated Show resolved Hide resolved
lighthouse-core/computed/page-dependency-graph.js Outdated Show resolved Hide resolved
@patrickhulce
Copy link
Collaborator

patrickhulce commented Dec 9, 2020

shoot, it looks like basics weren't failing because test-lantern wasn't finding the touched files anymore 🤦

CHANGED_FILES=$(git --no-pager diff --name-only $TRAVIS_COMMIT_RANGE)

@warrengm warrengm requested a review from patrickhulce December 9, 2020 19:26
Copy link
Collaborator

@patrickhulce patrickhulce left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

impl looks great, thanks for sticking with this @warrengm! would you be able to rebase with master to incorporate #11801 just to make sure the lantern tests are good in CI too before we merge?

lighthouse-core/lib/network-request.js Outdated Show resolved Hide resolved
@warrengm
Copy link
Contributor Author

Done. Rerunning the checks now!

@paulirish
Copy link
Member

Done. Rerunning the checks now!

image

booyah!

@patrickhulce patrickhulce merged commit 7915708 into GoogleChrome:master Dec 11, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants